Related, commonly assigned U.S. patent applications, listed hereinabove, describe a novel carrier management architecture for rating items to be shipped by a carrier. A shipping carrier is a company that provides shipping services for letters, packages, bulk goods, or any other item to be shipped. Carriers can perform a variety of shipping services. For example, they can deliver express shipments, e.g. airmail for letters and second-day air for small packages. Moreover, carriers can deliver ground shipments for packages, or “LTL” shipments for bulk goods. The term “LTL” means “Less Than Truckload” and applies to any ground carrier shipment of standard commodities, for example, rated in units of hundreds of pounds. Shipments of bulk goods or standard commodities usually occupy a portion of a truck trailer, hence “less than truckload,” but may require an entire truckload, occasionally known as “TL” shipments.
Each carrier has its own rate structure for charging shippers for transporting their goods. Typically, these rates structures are complex and involve a variety of factors. For example, carriers often charge different prices by weight, sometimes with different weight classifications. As another example, carrier rates may depend on the distance to the destination. In addition, some carriers charge a premium for shipping classes, e.g. first class and second class, with shorter or longer guaranteed delivery times. In some cases, carriers may grant discounts for volume. Thus, the business rules for rating items to be transported varies greatly from carrier to carrier. These rating calculations may change over time for a particular carrier as its rates and business rules are updated. Accordingly, it is desirable to provide mechanisms for logistics systems for shipping goods to facilitate updating how carrier rates are calculated.
As described in the related applications and illustrated in FIG. 1, a logistics system 100 includes a first client application 110, which is configured to perform various shipping tasks. At least some of the functionality for rating items to be shipped by a carrier is performed by a run-time loadable carrier management module 102. Carrier management module 102 is configured to access entries in a system registry 104 for run-time loading one or more carrier rate modules 106. More specifically, the carrier rate modules 106 are loaded into the executable space of the first client application 110, thereby avoiding the use of resource intensive inter-process communication (IPC) mechanisms (e.g. named pipes, etc.)
Each carrier rate module 106 includes program instructions to accesses carrier rate data 108 and rate items using business rules encapsulated therein together with accessed carrier rate data 108 for an associated carrier. After loading a carrier rate module 106, the carrier manager module provides an entry point in the carrier rate module 106 to the first client application 110. In this manner, the first client application 110 can invoke the instructions in the carrier rate module 106 to rate item for the carrier associated with the carrier rate module 106.
The carrier management module 102, moreover, can also be loaded by a second client application 120 for utilizing the carrier rating functionality of the carrier rate modules 106 as described hereinabove in connection with the first client application 110. Thus, isolated carrier rate modules 106, managed by a carrier management module 102, are arranged to provide carrier rating functionality for a plurality of client applications 110 and 120.
In some implementations, the versions of the first client application 110 may have developed before the carrier manager architecture described herein was designed. For example, the first client application 110 may be a shipping application for rating letters and packages shipped by express carriers. When the carrier manager architecture was designed, it is relatively easy to upgrade the first client application to access the carrier management module 102 for the carrier rating functions in the new carrier rate modules 106. In the example, the new carrier rate modules may contain LTL rating routines for shipping items by truck. Thus, to add trucking functionality to the legacy shipping application, it is relatively straightforward to call the new carrier management module 102 to load the carrier rate modules 106 for LTL rating.
The first client application 110 still includes the prior carrier rating routines of its own for rating items based on carrier rate data 112 for carriers not supported by the carrier rate modules 106. In the example, the shipping application still contains routines for rating letters and packages on supported carriers. However, it is difficult to extract the carrier rating routines from the first client application 110 for creating a new carrier rate module 106. Legacy systems tend to break if large-scale modifications are made thereto such as replacing the carrier rating routines in favor of the carrier manager architecture.
Keeping the carrier rating routines in the first client application 110 instead of in the carrier rate modules 106 means that rating functionality for those carriers are not available to the second client application 120. In the example, the second client application 120 may be a load planning application. In the configuration depicted in FIG. 1, the load planning application (i.e. second client application 120) only has access to the LTL rating routines in carrier rate modules 106, not to the express or ground carrier rating routines embedded in the legacy shipping application 110. Thus, it is desirable to make that carrier rating functionality of the first application 110 available to the second application 120, without having to make large-scale modifications to the first application 110. The first client application 110, however, may be implemented in a programming language or environment in which it is very difficult or impossible to receive requests directly from the second client application 120 for rating items for the first carrier.